Introducción
Una HU describe una funcionalidad que, por sí misma, aporta valor al usuario. (eXtremme Programing XP).
Son una forma rápida de administrar los requisitos cambiantes de un proyecto.
Una Historia de Usuario se compone de tres elementos (“las tres Cs”):
Las historias se priorizan en función de su valor para la organización.
Las entregas (releases) y las iteraciones se planifican colocando historias en iteraciones.
La velocidad es la cantidad de trabajo que los desarrolladores pueden completar en una iteración.
La suma de las estimaciones de las historias colocadas en una iteración no puede exceder la velocidad prevista por los desarrolladores para esa iteración.
Si una historia no cabe en una iteración, puede dividir la historia en dos o más historias más pequeñas.
Vale la pena usar las historias de usuarios porque enfatizan la comunicación verbal, el cliente y los desarrolladores pueden entenderlas por igual, se pueden usar para planificar iteraciones, funcionan bien dentro de un proceso de desarrollo iterativo y porque fomentan el aplazamiento de los detalles.
Cuando una historia de usuario es demasiado grande se la denomina épica.
Generalmente se clasifican en una de las siguientes categorías:
Las historias compuestas y complejas se pueden dividir en múltiples historias más pequeñas.
Una tarjeta de historia es la parte visible de una historia, pero las partes importantes son las conversaciones entre el cliente y los desarrolladores sobre la historia.
El equipo del cliente incluye a aquellos que se aseguran de que el software satisfaga las necesidades de los usuarios previstos. Esto puede incluir testers, un gerente de producto, usuarios reales y diseñadores de interacción.
El equipo del cliente escribe las story-cards porque están en la mejor posición para expresar las características deseadas y porque luego deben poder trabajar en los detalles de la historia con los desarrolladores y priorizar las historias.
Una buena historia será:
Para recordarlas se propone el acrónimo INVEST.
Mike Cohn sugiere una determinada forma de redactarlas:
Como [rol] quiero [funcionalidad] para [beneficio].
Idealmente, las historias son independientes entre sí. Esto no siempre es posible, pero en la medida en que lo sea, las historias deben escribirse de modo que puedan desarrollarse en cualquier orden.
Los detalles de una historia se negocian entre el usuario y los desarrolladores.
Las historias deben escribirse de manera que su valor para los usuarios o el cliente sea claro. La mejor manera de lograr esto es que el cliente escriba las historias.
Las historias se pueden anotar con detalles, pero demasiados detalles oscurecen el significado de la historia y pueden dar la impresión de que no es necesaria una conversación entre los desarrolladores y el cliente.
Una de las mejores formas de anotar una historia es escribir casos de prueba para la historia.
Si son demasiado pequeños, se pueden combinar varias historias pequeñas en una historia más grande.
Ayudan a entender mejor cómo se espera que el producto se comporte frente a ciertas situaciones.
Ayudan a resolver ciertas expectativas y permiten que el desarrollo sea más fluido, claro y con menor incertidumbre para el equipo.
Además:
Técnicas de comportamiento:
Dada una condición, cuando ocurre un evento o acción, entonces sucederá una consecuencia. Así se consigue una estructura consistente que se trasladará fácilmente a tests automáticos.
Técnicas de escenarios:
Suele definir el escenario normal o usual y un escenario alternativo de la funcionalidad en cuestión, y debe describir cómo el usuario ejecutaría o intentaría ejecutar los diferentes pasos en dichos trayectos.
Hay diferentes formas de escribirlos, las más usadas utilizan el lenguaje específico para las descripciones de comportamiento de software conocido como gherkin. La sintaxis de gherkin es la siguiente:
Dado que [Contexto 1] y adicionalmente [Contexto 2], cuando [Evento], entonces [Resultado / Comportamiento esperado]
Ejemplo:
Dado que el gps está activado, cuando se despliegue el listado de deliverys, entonces el sistema desplegará una lista con todos los deliverys ordenados según la valoración y la ubicación que se encuentra el usuario.
Newkirk y Martin recomiendan la práctica de anotar una historia con la palabra CONSTRAINT para cualquier historia que debe ser obedecida en lugar de implementada directamente.
Tareas de investigación durante una iteración. Por ejemplo: investigar, diseñar, explorar, comprender mejor un requisito, o aumentar la fiabilidad de estimación de una HU.
Suelen ser de dos tipos: técnicos o funcionales.
Si bien cada usuario llega a su software con antecedentes diferentes y con objetivos diferentes, aún es posible agregar usuarios individuales y pensar en ellos en términos de roles de usuario. Un rol de usuario es una colección de atributos definitorios que caracterizan a una población de usuarios y sus interacciones previstas con el sistema.
La mayoría de los equipos de proyecto consideran un solo tipo de usuario. Esto conduce a un software que ignora las necesidades de al menos algunos tipos de usuarios.
Para evitar escribir todas las historias desde la perspectiva de un solo usuario, identifique los diferentes roles de usuario que interactuarán con el software.
Al definir atributos relevantes para cada rol de usuario, puede ver mejor las diferencias entre los roles.
Algunos roles de usuario se benefician de ser descritos por personas. Una persona es una representación imaginaria de un rol de usuario. A la persona se le da un nombre, una cara y suficientes detalles relevantes para que parezca real para los miembros del proyecto.
Para algunas aplicaciones, los caracteres extremos pueden ser útiles para buscar historias que de otro modo se perderían.